Scratch project saving and loading outline#695
Conversation
There was a problem hiding this comment.
Pull request overview
This PR implements a scaffold for Scratch project integration by adding routes and authentication mechanisms for Scratch to save and load projects and assets through the editor API. The implementation demonstrates cookie-based authentication as a workaround for Scratch's inability to send custom headers, while the actual project/asset storage is stubbed with static responses.
Changes:
- Added cookie-based authentication mechanism for endpoints that can't send Authorization headers
- Created Scratch-specific API routes for projects and assets with feature flag gating (cat_mode)
- Added CODE_EDITOR_SCRATCH as a new project type
- Configured CORS to allow credentials for Scratch and projects routes
Reviewed changes
Copilot reviewed 14 out of 15 changed files in this pull request and generated 14 comments.
Show a summary per file
| File | Description |
|---|---|
| app/models/project.rb | Adds CODE_EDITOR_SCRATCH as a new project type constant |
| app/controllers/concerns/identifiable_by_cookie.rb | New concern for cookie-based authentication extracting token from scratch_auth cookie |
| app/controllers/api/scratch/scratch_controller.rb | Base controller for Scratch endpoints with cookie auth and cat_mode feature flag checks |
| app/controllers/api/scratch/projects_controller.rb | Stub implementation for showing/updating Scratch projects (returns static JSON) |
| app/controllers/api/scratch/assets_controller.rb | Stub implementation for showing/creating Scratch assets (returns static SVG/JSON) |
| app/controllers/api/projects_controller.rb | Sets scratch_auth cookie when loading CODE_EDITOR_SCRATCH projects with cat_mode enabled |
| config/routes.rb | Adds Scratch namespace routes for projects and assets |
| config/initializers/cors.rb | Enables credentials for Scratch and projects routes to allow cookie transmission |
| app/views/api/scratch/projects/show.json | Static Scratch project JSON with example blocks and sprites |
| app/views/api/scratch/assets/show.svg | Static SVG asset (teapot image) |
| spec/requests/projects/show_spec.rb | Tests cookie setting behavior for CODE_EDITOR_SCRATCH projects |
| spec/features/scratch/showing_a_scratch_project_spec.rb | Tests GET endpoint returns Scratch project JSON |
| spec/features/scratch/updating_a_scratch_project_spec.rb | Tests PUT endpoint with cookie authentication and feature flag |
| spec/features/scratch/showing_a_scratch_asset_spec.rb | Tests GET asset endpoint returns SVG |
| spec/features/scratch/creating_a_scratch_asset_spec.rb | Tests POST asset endpoint with cookie authentication and feature flag |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
zetter-rpf
force-pushed
the
scratch-auth-and-loading-spike
branch
from
a54f922 to
0c6cef7
Compare
zetter-rpf
force-pushed
the
scratch-auth-and-loading-spike
branch
from
0c6cef7 to
5570bad
Compare
Test coverage89.7% line coverage reported by SimpleCov. |
mwtrew
left a comment
mwtrew
left a comment
There was a problem hiding this comment.
Using the cookie as well as the auth header does make me wonder about invalidation - could we find ourselves e.g. in a situation where the auth token has expired but the cookie hasn't? Any thoughts on that?
Looks good though, and is a nice scaffold for the rest of the backend work - thanks!
It's certainly possible. For loading project's it's less likely as you would hit the existing API just before you hit the new one with the Scratch token. It might be more of a problem for project saving. I'll write write an issue investigate it - I'm not sure how well we handle it for existing tokens expiring at the moment. |
This feels like a sensible place as it should always be set before a scratch project is loaded We may need to extend this when creating/remixing projects if it uses another path. Alternatively we could make a new endpoint that creates a cookie.
This shows a static project for now, later we will likely pull project data from the database or object store. The updating always succeeds and returns an ok but doesn't perform any updates.
For now, the show always returns a static asset and the create always succeeds but doesn't do any saving. Note that the /internalapi/asset/.../get/ route is dictated by Scratch.
zetter-rpf
force-pushed
the
scratch-auth-and-loading-spike
branch
from
5570bad to
7673d6d
Compare
Status
What's changed?
This is an outline/scaffold for the routes needed to show & update scratch projects and show and create scratch assets. There is a static project and asset that is loaded whatever ID is provided, and updates are authorised but not performed.
The main reason for this work is to demonstrate a route to authenticating asset creation and project updates. It can also be a base that we can add in the future to load and save real data.
See the documentation for the endpoints that scratch expects.
The authentication mechanism
We use header-based auth elsewhere in the API but Scratch does not allow us to add headers to requests, but it does send cookies with the asset post and project put requests.
The flow is:
I've limited where this cookie can be used to just the scratch controllers (and CORS rules block sending cookies for other routes). As the auth token was already accessible to Javascript, I don't think this adds additional risk.
Not considered in this PR
projectToken.).After deploy